昨天我們先談了一件事。
AI 已經很強，但企業真正擔心的，通常不是它夠不夠聰明，而是：

如果把事情交給它，我敢不敢接受它的結果？

所以在 Day 1，我們先定義了一個最基本的方向：
我們不是要做一隻「很會回答」的 AI。
而是要做一個：
有證據、懂邊界、可追溯、可控制的審核型 AI 系統。

今天我想往前再走一步。
但這一步，我反而不想先碰 Prompt，也不想先談 RAG，更不急著談 Agent。
我想先問一個更基本的問題：

審核，到底是在審什麼？

這句話看起來很簡單，但我認為它其實是很多 AI 專案最容易跳過的一步。

很多 AI 專案，第一步就衝太快

我在企業裡看過很多需求。
需求單位會說：

這件事情現在都靠人工判斷，可以做成 AI 嗎？
或者：
我們每天有很多單據要看，希望 AI 可以先幫忙審。
這個時候，工程端很容易立刻開始想：

要用哪一個 LLM？
Prompt 怎麼寫？
要不要用 RAG？
要不要做 Agent？
要串哪些 API？

這些都沒有錯。
但我通常會先把這些問題放旁邊。
我會先問需求單位：

你現在人工到底在做哪幾件事情？
因為一句「人工審核」，背後可能混著很多完全不同類型的工作。
而這些工作，不一定都應該交給 AI。

還是回到昨天那張異常申請單

我們繼續用同一個案例。
某張製令：
標準材料耗用：
100 kg

實際材料耗用：
107 kg

現場填寫原因：

因設備切換，起機過程產生額外損耗，申請認列為正常製程損耗。

主管收到這張單之後，表面上看起來是在做一件事情：

審核。

但如果真的把主管腦袋裡的工作拆開，其實至少包含下面幾層。

第一層：資料有沒有填完整？

例如：

• 工單號有沒有填？
• 異常原因有沒有填？
• 實際耗用量有沒有資料？
• 標準耗用量有沒有資料？
• 必要附件有沒有上傳？
• 申請人是不是這張工單的相關人員？

這一層的工作，其實非常明確。
假設欄位「工單號」不能是空值。
那程式只要檢查：

work_order != null

就好了。
假設附件至少要有一份。
那也只是：

attachment_count >= 1

這類問題根本不需要 LLM。
而且我甚至會說：

能用明確規則處理的事情，就不要先交給 AI。
原因很簡單。
程式判斷空值，不會今天說有、明天說沒有。
它不會有語意理解偏差。
也沒有 Token 成本。
最重要的是：
結果可預期。

第二層：數字是不是超過標準？

這也是企業審核非常常見的一層。
我們先算材料差異率：

Deviation
= (Actual - Standard) / Standard

代入數字：

= (107 - 100) / 100
= 0.07
= 7%

假設公司規定：

正常容許差異：±3%

那結果就是很清楚：

7% > 3%

超過標準。
這件事情應該讓誰算？
LLM 嗎？

我認為答案不該是這樣，因為這就是標準的程式計算。
應該直接寫成：

if deviation > 0.03:
    status = "OUT_OF_RANGE"

乾淨、清楚，而且很好測試。

為什麼我一直強調這些「看起來很基本」的東西？

因為現在生成式 AI 太強了。
強到我們有時候會產生一個錯覺：

既然 AI 什麼都能做，那乾脆全部丟給它。

例如我們可以直接問：

「107 kg 相對於 100 kg 的標準，是否超過 3%？」
LLM 當然多半答得出來。

但是「做得到」跟「應該這樣做」，是兩回事。
這是我很想在這個系列一直提醒大家的一件事。

第三層：規則是否符合？

再往下深思一層。
假設公司制度規定：

差異 <= 3%
可正常結案
3% < 差異 <= 5%
需主管覆核
差異 > 5%
需提出異常說明並由部門主管核准

那這仍然是很標準的 Rule Engine（規則引擎）問題。
可以直接寫成：

IF deviation <= 3%
    PASS
ELSE IF deviation <= 5%
    SUPERVISOR_REVIEW
ELSE
    HIGH_RISK_REVIEW

這一層我仍然不需要 LLM。

所以目前為止：

資料完整性 → 程式
數值計算   → 程式
明確規則   → Rule Engine

AI 還沒出場。
但系統其實已經做掉了一大半工作。

第四層：申請人寫的原因合理嗎？

這時候事情才開始有趣。
申請人寫：

因設備切換造成起機損耗。
現在我們要判斷的就不是單純數字了。
我們可能會想知道：

• 這個描述是不是在說「換線」？
• 還是在說「設備故障」？
• 還是其實是「人員操作問題」？
• 是否符合公司對異常原因的分類？

這種問題已經開始涉及：
語意理解。
這就是 LLM 比較擅長的地方。

例如：

「設備切換造成起機損耗」

和：

「換線後重新開機產生較多廢料」

文字不同，但其實可能是在描述同一件事。

傳統規則如果只靠關鍵字，很容易漏掉。
這就是 AI 真正開始有價值的地方。

第五層：他講的事情是真的嗎？

這一步我認為比「理解文字」更重要。
假設申請人說：

有設備切換。
那我們就去 MES 或設備紀錄查。
結果發現當天：

08:00 開機
08:15 生產開始
12:00 停機
12:10 生產結束

完全沒有換線紀錄。
那系統應該怎麼辦？

這時候不是叫 AI 判斷：

「設備切換這個理由聽起來合理。」
而是要做：
交叉驗證。
也就是：

申請人說明
vs.
MES 紀錄
vs.
設備事件

如果三者不一致，系統應該把這個衝突標記出來。

例如：

CLAIM:
有設備切換
SYSTEM RECORD:
查無設備切換紀錄
RESULT:
CONFLICT

這就開始進入我們後面會談的 Evidence Chain。

第六層：規範到底怎麼寫？

再下一步。
如果真的有設備切換，那我們還要問：

公司規範允不允許？
例如 SOP 寫：
設備切換所造成的起機損耗，於 5% 以內可由主管核准認列。
那現在：
實際差異是 7%。
所以即使：
設備切換是真的
也不代表：
這筆可以直接核准。

這裡就有一個很重要的差別：

原因成立
≠
符合規範

這也是審核系統常常容易混掉的地方。
LLM 很容易做語意上的「合理化」。
但是企業真正需要的是：

規範上的判斷。

第七層：這是一個低風險還是高風險案件？

再往下走一層。
同樣是 7% 差異。
如果這筆工單總金額只有 5,000 元，
跟這筆工單影響 500 萬元，
風險一樣嗎？
當然不一樣。

所以審核裡通常還會有：

金額
品質影響
客戶影響
製程風險
法規風險
歷史異常頻率

這些因素。

最後才形成：

LOW
MEDIUM
HIGH

不同風險，再決定是否需要不同層級的人介入。

所以，「審核」其實不是一個動作

拆到這裡之後，我們可以重新看一次。
一張看起來很簡單的異常申請單，背後可能包含：

1. 資料完整性檢查
2. 數值計算
3. 明確規則判斷
4. 文字語意理解
5. 系統資料查證
6. 規範文件比對
7. 衝突偵測
8. 風險評估
9. 決策建議
10. 最終核准

這十件事情的性質完全不一樣。
但如果我們一開始只說一句：

做一個 AI 幫我審核。

很容易全部打包丟給同一個 LLM。
這就是我認為很危險的地方。

這裡我要先分兩種世界

我會把這十件事情簡單分成兩種。

第一種：Deterministic

Deterministic 可以翻成：
確定性的。
同樣的輸入，理論上應該得到同樣的結果。
例如：

107 - 100 = 7

或者：

7% > 3%

或者：

工單號不能為空

這類事情，我希望結果是固定的。

它就適合：

程式
Rule Engine
Database Constraint
Workflow

來處理。

第二種：Probabilistic

Probabilistic 可以翻成：
機率性的。
例如：

「這一段文字比較接近設備異常還是換線異常？」
這種事情很難用一條 if-else 完整處理。
LLM 就很有價值。
所以：

語意理解
文件摘要
原因分類
上下文比較
複雜文字判讀

可以考慮交給 AI。

我自己的原則很簡單

如果一件事情：

能用 100% 明確的規則解決，我不會先用 90% 準確的 AI 去解。
不是因為 AI 不好，而是因為沒有必要。

這也是 AI Engineering 很重要的一種能力：

知道 AI 要放在哪裡，也知道 AI 不該放在哪裡。

AI 用得越深，越要知道何時該放手

這句話我想特別放在今天。
很多時候，我們剛開始使用 AI，會一直想：

還能不能多給它一點能力？
從：

回答問題

一路變成：

查資料

再變成：

呼叫 API

再變成：

自己選 Tool

最後甚至變成：

自己做決策
自己執行

能力一路往上加。

但我覺得真正成熟的做法，反而是另一條線也要一起長出來：

什麼時候該停？
例如：

資料不足 → 不判斷
文件衝突 → 不判斷
風險太高 → 不判斷
超過權限 → 不執行
規則可以確定 → 不需要 AI

所以我很認同一句話：

AI 用得越深，越要知道何時該放手。

這裡的「放手」，不是放棄 AI，而是知道：
什麼時候應該把事情交回給規則、系統，或者人。

真正可靠的 Agent，不是什麼事情都搶著做。
而是知道自己的邊界。

這其實很像帶一個新人

這裡用一個很生活化的例子來理解。
假設今天來了一位新人。
第一天你不會直接跟他說：

從今天開始，公司所有異常單都交給你核准。

你可能會先讓他：

整理資料
↓
查制度
↓
做初步判斷
↓
整理證據
↓
提出建議
↓
主管確認

等他慢慢熟悉之後，再增加權限。
其實 Agent 也一樣。
我們不應該因為模型很強，就直接給它最大的權力。
能力跟權限，是兩回事。
這也是我認為很多 Agent 系統容易忽略的地方。

能力不等於權力

這個觀念我想再講清楚一點。
今天某個 LLM 可能：

可以分析財報
可以操作資料庫
可以寄 Email
可以呼叫 ERP API
可以修改資料

這些叫：
Capability，能力。

但是公司應不應該允許它：

修改 ERP
直接送出交易
直接核准
直接寄給客戶

這叫：
Authority，權力。
能力很強，不代表權力就應該開到最大；這跟人一樣，一個工程師可能技術很好，也不代表他可以直接修改正式環境所有資料。

企業系統本來就有：

Role
Permission
Approval
Separation of Duties

AI 也不應該例外。

所以我們的 Review Agent 到底要做哪些事情？

走到這裡，我們可以先幫 Review Agent 做第一版工作分工。
我會把它拆成這樣。

1. Data Validator

負責：

欄位完整
格式正確
必要資料存在

這裡不用 AI。

2. Rule Engine

負責：

差異率
金額門檻
明確制度規則

這裡也不需要 LLM。

3. Evidence Retriever

負責：

找 SOP
找歷史案件
找 MES 紀錄
找相關文件

這裡後面會開始用到 RAG 和 Tool。

4. LLM Analyzer

負責：

理解異常原因
比較不同 Evidence
找出衝突
整理判斷理由

這才是 LLM 的核心工作。

5. Risk Engine

負責：

低風險
中風險
高風險

這裡可能是 Rule + AI 的混合。

6. Human Reviewer

負責：

高風險案件
低信心案件
資料衝突案件
最終責任

注意。
Human 不是我們做不好的補強。
而是架構裡正式的一個 Component。
這件事情非常重要。

一個常見的錯誤：什麼都想用 AI

我舉一個很簡單的例子。
假設我們問 LLM：

請計算 107 比 100 高多少百分比，
如果公司規定超過 3% 要人工覆核，
請判斷是否需要人工覆核。

模型很可能回答：

差異為 7%，
超過 3%，
因此需要人工覆核。

完全正確。
Demo 也很好看。
但正式系統我還是不會這樣做。

我會拆成：

程式：
Deviation = 7%
Rule Engine：
7% > 3%
→ HUMAN_REVIEW

LLM 根本不用參與。
為什麼？
因為：

數值計算
+
明確規則

本來就是軟體最擅長的事情。

不要因為現在 AI 很紅，就把已經做得很好的東西重新做差。

AI Engineering 不是 AI Everything

這句話我也很想留在 Day 2。
AI Engineering 並不是：

所有東西都要 AI。

而是：

怎麼把 AI 放到真正需要 AI 的位置上。

傳統 Software Engineering 不會消失。
Rule Engine 不會消失。
Database 不會消失。
Workflow 不會消失。
反而是 AI 越深入企業，這些傳統工程能力越重要。

因為最後真正可靠的系統通常會是：

Software
+
Rule
+
Data
+
AI
+
Human

一起完成。

而不是：

Everything → LLM

今天的結論

Day 1 我們問：

為什麼企業不敢讓 AI 簽核？

今天我們再往下拆一層。
答案之一就是：

因為我們常常沒有先定義，哪些事情到底應該由誰負責。

不是每個問題都需要 AI，也不是 AI 能做，就應該讓它做。

我自己會把今天的重點整理成三句話。
第一句：

能用明確規則處理，就不要先交給機率模型。
第二句：
Capability 不等於 Authority。
AI 有能力，不代表我們要給它相同程度的權力。
第三句：
AI 用得越深，越要知道何時該放手。
一個真正成熟的 Agent，不只是知道：
我可以做什麼。
還要知道：
什麼時候不該由我做。

明天：先做一個完全不用 LLM 的版本

Day 3，我想再做一件更反直覺的事。
我們會先暫時把 AI 拿掉。
直接用：

Rule Engine
+
Risk Level
+
Approval Matrix

做出第一版審核系統。
因為在加入 AI 之前，我們需要一個可以比較的：
Baseline（基準線）。

不然未來即使加了 LLM、RAG、Agent，我們也沒有辦法回答一個最基本的問題：

AI 到底讓系統變好了多少？

下一篇，我們先從最笨、但最可靠的版本開始。